在 Elixir 中，我們摒棄了透過修改狀態來進行指令式編程的模式，轉而採用一種以流程為基礎的方法，讓程式成為一系列獨立的 純粹的轉換。取而代之的是，我們不需告訴電腦 如何 去改變一個值，而是定義一個函數的處理流程，其中 程式設計應聚焦於資料轉換。
1. 不可變性原則
在 Elixir 中， 所有值都是不可變的一旦資料建立，便無法被更改。這確保了 不可變資料即是已知資料——資訊永遠不會意外地改變，從而消除大量與狀態相關的錯誤。這種轉換從不修改資料；相反地，每個函數都會產生一個 全新且完整的版本 的資料。
2. 管道哲學
管道運算子（|>）將資料視為像流體般在工廠生產線上移動。函數式程式語言讓我們能以逐步轉換資料的函數觀點來思考問題。
3. 執行者情境
在 Erlang 虛擬機（BEAM）中，程式碼運行於 極小的並行處理程序，每個都有自己的狀態。 處理程序之間透過訊息溝通。由於通訊是透過訊息傳遞的方式進行，因此在不同機器間交換資料時，虛擬機會自動透明處理。
main.py
TERMINALbash — 80x24
> Ready. Click "Run" to execute.
>
QUESTION 1
What happens to the original data when a function is applied in Elixir?
The data is mutated in-place to save memory.
A new, fresh version of the data is potentially created.
The original data is deleted immediately.
The VM locks the memory address until the transformation finishes.
✅ Correct!
Correct! Elixir transformations never mutate data; they return new values while keeping original data intact.❌ Incorrect
Recall that in Elixir, all values are immutable and cannot be altered once created.QUESTION 2
What is the primary purpose of the pipe operator (
|>)?To compare two values for equality.
To terminate a concurrent process.
To flow data through a series of discrete transformations.
To bind a variable to a memory address.
✅ Correct!
Exactly. It takes the output of the expression on the left and passes it as the first argument to the function on the right.❌ Incorrect
The pipe operator is a syntactic driver for data transformation, not comparison or process termination.QUESTION 3
How do processes in the Erlang VM communicate with one another?
By sharing a global mutable state object.
By passing messages to one another.
By reading each other's local variables.
Through direct pointer manipulation.
✅ Correct!
Yes! Processes are isolated and communicate only via message-passing.❌ Incorrect
Shared state is avoided in Elixir to prevent race conditions; message passing is the only way.QUESTION 4
Why is 'Immutable Data Known Data' considered a benefit?
It allows the computer to run faster without a CPU.
It guarantees that a value will not change unexpectedly behind your back.
It prevents the developer from using variables.
It means the code doesn't need to be compiled.
✅ Correct!
Correct. This certainty eliminates side-effect bugs common in imperative languages.❌ Incorrect
Immutability is about state predictability and thread safety, not CPU-less execution.QUESTION 5
Which of these is a core philosophy of Elixir's approach to concurrency?
Shared-memory multi-threading.
A single process for the entire application.
An actor-based approach with tiny concurrent processes.
Manual mutex and semaphore management.
✅ Correct!
Indeed. Elixir uses the Actor model where processes are extremely lightweight.❌ Incorrect
Elixir avoids shared-memory conflicts by using isolated processes and message passing.Case Study: The Bicycle Factory
Applying Functional Transformation Logic
Imagine a manufacturing line for a bicycle. In an imperative language, you have one bicycle object and you 'bolt parts' onto it, changing its internal state. You are tasked with modeling this in Elixir.
Q
If you have a function 'add_wheels(frame)', what does it return in Elixir?
Solution:
It returns a new piece of data representing 'Frame + Wheels'. The original 'Frame' remains pristine and unchanged in memory.
It returns a new piece of data representing 'Frame + Wheels'. The original 'Frame' remains pristine and unchanged in memory.
Q
How would you chain the 'add_wheels', 'add_seat', and 'paint_red' functions for a 'frame' variable?
Solution:
Using the pipe operator: frame |> add_wheels() |> add_seat() |> paint_red().
Using the pipe operator: frame |> add_wheels() |> add_seat() |> paint_red().
Q
If two different processes access the 'frame' variable at the same time, is a lock required?
Solution:
No. Because the frame is immutable, both processes can read the same data safely without risk of it changing mid-operation.
No. Because the frame is immutable, both processes can read the same data safely without risk of it changing mid-operation.